The Third Generation Partnership Project group, known as 3GPP, is involved in ongoing standardisation work on the WCDMA group of protocols referred to as UMTS or 3G. A UMTS operator network can be separated into a number of major components, namely one or more core networks which are responsible for setting up and controlling user sessions, and a UMTS Radio Access Network (UTRAN) which controls access to the air interface. The architecture of a UTRAN is illustrated schematically in FIG. 1. The interface between the UTRAN and the user equipment (UE) is provided by nodes referred to as “NodeBs”. The NodeBs are responsible for transmitting and receiving data over the air interface and are controlled by Radio Network Controllers (RNCs). User and control data is routed between UEs and a core network via the NodeBs and the RNCs. The interface between a NodeB and an RNC is referred to as the Iub interface.
There are situations in which the same data may be transmitted between a given UE and an RNC via two or more NodeBs. This is referred to as Diversity Handover Function (DHO). The NodeBs may be controlled by the same or different RNCs. In the latter case, data is routed to the controlling (or serving) RNC via a drift RNC. The interface between the serving and the drift RNC is referred to as the Iur interface. Both scenarios are illustrated in FIG. 1.
The user-plane protocols between an RNC, NodeB, and UE are illustrated schematically in FIG. 2. One job of these (UP) protocols is the implementation of a Frame Synchronization function which takes care of the timing of frames over the Iub interface between an RNC and the associated NodeB's. An important function influencing Frame Synchronization is the handling of the DHO scenario in which the same frames are transmitted over a number of legs, some of which also may be relayed via a Drift RNC over the Iur interface. In the downlink direction, as the transmission over the air has to be synchronized, the Frame Synchronization function has to make sure that copies of the same frame received over different Iub's/Iur's with differing delays are received on time for sending. FIG. 3 illustrates the frame synchronisation window at a NodeB in relation to the (DL) radio frame structure, where the time taken to process a frame at the NodeB is defined as Tproc. In the uplink direction, the serving RNC must coordinate the receipt of identical frames received over the different Iub's/Iur's, and again the Frame Synchronization function must ensure that frames are received at the serving RNC on time.
Considering further the downlink direction, a certain frame with an associated CFN number must be transmitted over the air at a given time. If there are several NodeBs and Iub/Iur links involved, all NodeBs have to transmit that particular frame at the same time. Assuming that the delays over the Iub links differ, the serving RNC must send the frame with a sufficient time-offset, so that the frames are received at all transmitting NodeBs on time. Those NodeBs “behind” a fast Iub link must buffer the frames until the scheduled time for transmission.
To supervise this function, 3GPP TS 25.402 specifies parameters defining a “Receiving Window”, which facilitates monitoring of whether frames are received early or late at a NodeB. These parameters are illustrated in FIG. 3. The window serves as a ‘target’ so that ToAWS (rime of Arrival Window Start point) defines the earliest point and the minimum buffering capability needed by the NodeB, while the ToAWE (Time of Arrival Window End point) defines the latest ‘desired’ arrival time of a frame. Frames received during the period between ToAWE and a LtoA (Latest Time of Arrival) point are considered late, but not too late for transmission. Frames received after LtoA are discarded. The standard specifies how the NodeB shall report to the RNC in case the frames are received outside the widow, so that the RNC can adapt its offset accordingly: for each frame received outside the Receiving Window, the NodeB shall respond with a “Timing Adjustment” frame, indicating the ToA (Time of Arrival) of the frame, so that the serving RNC can adjust its offsets.
In order to make sure that all NodeBs receive frames on time, the Frame Synchronization must be in a “worst-case” mode, where the Iub/Iur “leg” with the worst delay is ruling the offset. A similar approach may be applied to ensure frame synchronisation in the uplink direction.
The standard 25.402 supports certain tools Or Timing adjustment and ToA monitoring on the Iub/Iur interfaces. One such tool simply involves trusting the “Receiving Window” function as described above. However, in order to receive frequent and trustworthy measurements of the frame-arrival process, it would be necessary to define a very narrow window such that frequent feedback from the receiving node (RNC or NodeB) is achieved. This is far from ideal, as to do so would generate a lot of reverse link traffic. With very small windows, the messages from different receiving nodes could also be ambiguous, with one receiving node reporting a need to reduce the offset, while another is reporting a need to increase it. In practice, a rather large window (based on pre-configured parameters settable by the operator) tends to be defined. Timing adjustments are assumed to be very rare. Thus, the window-mechanism is not used in practice for offset tuning—rather it is used as a tool for recovering from fault events. Of course the result of adopting this approach is that there is no means for actively monitoring and adapting the offset timing in real or near real-time, and the offset delay used for frame synchronisation is likely to unnecessarily delay the end-to-end transfer of data, especially during periods of relatively light loading of the data link (or a favourable transport topology).
A second tool for determining timing adjustments involves using DL Synchronization Control frames. The specification 25.402 defines that the NodeB must always respond to the receipt of such a frame with a UL Synchronization Control frame including the value of the ToA of the DL Synchronization Control frame. However, the DL Synchronization Control frames can only be sent when no DL data frames are sent. This means that the ToA monitored with this procedure does not provide a reliable measure of the “true” ToA characteristics of data frames. In addition, in order to obtain high quality statistics of the ToA process, it would be necessary to perform frequent ToA measurements. A procedure using DL Synchronization Control frames would result in excessive extra traffic in both the up- and downlink directions. For an “active” connection with a lot of traffic, it is not possible to use this function. It is noted that there is no standardised solution for the uplink direction, equivalent to this approach. Uplink solutions are vendor specific.